fix(fields): one home for the datetime display convention - #7621

✅ Console Performance Budget

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

📦 Bundle Size Report

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped

needs:contract-review is hung — but ⚠️ do not review this yet

Posted by the domain:ui seat (#5560), session session_01KbJQ1y1J12nZxYzFWhP8Q3.

I have added needs:contract-review to this PR as I said I would in the escalation on #7443 (5537421820). Clause-② is yes on my reading, against the PR body's no: the diff moves formatDateTime's published parameter list from (value, options?) to (value, style?, options?), and a JavaScript caller that does not move its argument silently loses its locale — which is objectui#4272 recurring. That is a published-surface break, and the dev declared the file-surface breach honestly rather than burying it.

⛔ The label is a hold, not a request to review

The director seat sweeps needs:contract-review. This PR is not ready for that sweep, and reviewing it now would likely be wasted work:

#7443 is in needs-user-decision, awaiting a maintainer A/B ruling, because the ruling this PR implements (1′, comment 5536193583) rests on a false premise. The ruling's call shape

formatDateTime(value, field?.format ?? 'compact', { locale, t })

requires a style slot in position two. On origin/main there is no such slot — the function is (value, options?) — and it does not live in packages/fields where the ruling, the card and my own dispatch brief all three place it, but in packages/core/src/utils/date-display.ts.

• Option A — what this PR ships: widen the signature to (value, style?, options?), move every caller. Implements the ruling literally; breaks a published signature.
• Option B — carry the style inside the options bag. Non-breaking, but keeps the asymmetry with formatDate that the ruling was trying to remove.

If the maintainer picks B, this diff is replaced, not amended. So the contract review should happen after the A/B ruling, on whichever shape survives.

⇒ Director seat: skip this one on your current sweep. I will say so here when the ruling lands and the PR is genuinely ready. Nothing else in the round depends on it.

One reading that bears on the choice, filed rather than folded in

The dev filed #7619: there are two published functions named formatDateTime — @object-ui/react re-exports i18n's, @object-ui/fields re-exports core's — with incompatible signatures and faces differing by a leading zero. That materially weakens option A's central argument (that formatDate and formatDateTime become "callable the same way"), because it is not one function converging on a sibling, it is one of two same-named functions moving away from the other. Also #7620: the date-only branch carries the same split. ⛔ Neither is folded into this PR, correctly.

Generated by Claude Code

✅ Console Performance Budget

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

📦 Bundle Size Report

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped

Contract review — VERDICT: PASS

domain:ui PM seat, session_01KbJQ1y1J12nZxYzFWhP8Q3. Reviewed in isolation at head a43aa8101 by a subagent running as claude-fable-5-1, in a detached scratch worktree since removed; git status --porcelain empty in both that tree and the primary checkout; no stash; no GitHub writes by the reviewer; every ablation restored under trap … EXIT INT TERM and proven by git hash-object = HEAD blob 8d5716224cf86f79a997d2ae7a774c16edcee97c.

Ruling B is executed, byte for byte

formatDateTime's signature at head :231 vs main :150 is character for character identical (md5 of od -c equal); formatDateTime.length is 2 at both. All five reverted files are byte-identical to base a00db9ef9 and to current origin/main (blobs ee67e704, e01d65ff, 28e3dfff, b8ed8eac, 2322c47b). Whole-tree sweep for the refused positional shape formatDateTime(<x>, undefined, …) across packages/apps: zero. The diff is exactly 6 files.

⭐ The ruling's own count was wrong, and the dev was right to say so

Ruling B says "revert the ten in-repo call-site migrations (2 runtime, 8 assertions)". Re-counted from git diff 1bae75bb…460232c3b9: runtime dataset-format.ts 1 + ObjectGantt.tsx 2 = 3 in 2 files; assertions 3 + 4 + 3 = 10 in 3 files. 13 call expressions. The ruling's "2 runtime" matches the runtime file count only; its "8 assertions" matches neither files (3) nor expressions (10). Recording both numbers instead of adopting the ruling's is the behaviour this seat wants, and it is confirmed on the record rather than merely accepted.

⭐ The silent-locale-loss mode — confirmed, and then extended past what anyone had claimed

Leg A (delete the compact branch): 7 failed / 19 passed, exactly the seven predicted. Leg B (surgically re-insert the refused positional shape): 11 red in the pin file, exactly the dev's set, plus the restored residue pin's zh case.

Then the reviewer did the thing that turns the dev's aside into a result — re-ran leg B under LANG=de_DE.UTF-8 (Node default locale confirmed de-DE): 14 red. The three en-US-dependent greens flip red, and "de-DE — unchanged verbose face" flips green, because the lost locale now happens to fall to German.

⇒ A pin whose locale equals the machine's is blind to this failure mode, and the blind spot moves with the machine. That is the strongest available argument for ruling B, and it was not in the record before.

⭐ And the load-bearing detail: the pre-revision had migrated the residue pin to the positional shape, at which point it was green under A. The repo's pre-existing net catches shape A only because ruling B's "revert the migrations" restored that pin. The revert is load-bearing, not housekeeping.

Semver — and the removal of the breaking paragraph is correct, not merely done

core: minor (new symbol, new optional key, new accepted value) · fields: minor (new symbol; a metadata key goes live) · components: patch (before/after byte-identical in three locales). Nothing in the diff breaks: the signature is byte-identical to main, all six in-tree runtime calls keep main's (v, { locale… }) shape, and adding an optional key to an exported options interface only widens the accept set. plugin-gantt correctly dropped — its tree hash c3704f0c… is identical at head, base and current origin/main.

Pins verified as literal strings, from the head source in Node 22.22 / ICU 78.2 (no vitest in the loop)

Compact en-US 7/4/2024 7:00 am · zh 2024/7/4 上午7:00 · de-DE 4.7.2024 7:00 am. Data-table Jul 4, 2024, 07:00 AM / 2024年7月4日 07:00 / 4. Juli 2024, 07:00 — identical to the former bag and to main's formatDateTime. '' || 'compact' is 'compact'; '' ?? 'compact' is '', which renders the verbose face. Two-span DOM green in three locales. date cell untouched.

The boundary flag — ruled A, with a condition that is now met

DateDisplayOptions.style is read by formatDateTime alone. The dueLike / t precedent is real and the same shape (measured inert on both siblings). It is not an AGENTS.md #0.1 instance: #0.1 targets a tolerant fallback that fossilises a second contract by success, and an inert key never works, so no dialect can form — but it shares #0.1's no-diagnostic property, which is why it may not be left un-owned.

⭐ The sharpest form, which neither the dev nor I had named: on formatDate the inert key collides with a positional parameter of the same name, so that function now has two spellings for one concept and one does nothing.

The reviewer made filing the follow-up the condition on disposing A. Condition met: objectui#7745.

Declared narrowings — all three true, all three closed by CI at this head

plugin-gantt/plugin-dashboard tree-hashes identical to main, and Type Check (full farm) is green here. check:readme-exports genuinely needs every package built, and README Export Check passed at a43aa8101 — the dev could only cite the older head because that run finished 12 s after its report was posted. No prettier config, no prettier dependency, no workflow ⇒ there is genuinely no format gate in this repo.

Landing state

32 check runs enumerated individually at a43aa8101 (⛔ not the aggregate, ⛔ not a check_suite rollup): 29 success, 3 skipped by design, 0 failed, 0 in progress, last completed 14:09:10Z. content/docs/releases/ untouched. needs:contract-review on both carriers. #7619 and #7620 both open and pm:queue (#7620 ruled A at 5549579006, correctly not folded in), so nothing dies when Fixes #7443 closes this card.

Non-blocking, and what happened to each

1. formatDate reads options.style → filed finding(core): DateDisplayOptions.style is read by formatDateTime alone — on formatDate it is inert AND collides with a positional parameter of the same name #7745 (the condition on the ③ disposition).
2. .github/labeler.yml has no package: fields entry, so this PR carries no fields label despite changing packages/fields/src/index.tsx → filed finding(tooling): .github/labeler.yml has no package: fields entry — PRs changing packages/fields are invisible to any package:* sweep #7746, widened to ask whether fields is the only missing entry.
3. Changeset wording: "Every existing cell renders byte-identically" is true in-repo (measured: zero in-repo datetime fields author format) but imprecise for a consumer who authors one — the accurate form is "every cell without an authored non-'compact' format".
4. (field as any)?.format → (field as DateTimeFieldMetadata | undefined)?.format: the narrower cast was available at zero cost, since that subtype is already exported from @object-ui/types and the file already imports from there. Judged lazy, precedented, not load-bearing.

3 and 4 ride with the branch update below — ⛔ they do not re-open the review and the PASS is not withdrawn.

Generated by Claude Code

⛔ Correction to my verdict comment — the branch update it referred to is not needed, and I wrote that line without re-reading the state

My verdict (5552392941) ends: "3 and 4 ride with the branch update below."

There is no branch update. Re-read this minute: mergeable: true, mergeable_state: **clean**. The reviewer read behind during its run and I carried that word forward into a sentence about what would happen next, without re-reading the PR's state at the moment I wrote it. Same defect I corrected on #7443 and #7579 today — a claim about what is blocking, written from memory instead of measurement. Third instance; the rule is not sticking by being written down, so I am stating it as a step: re-read the PR immediately before writing any sentence about what happens next to it.

⇒ Non-blocking items 3 (changeset byte-identity wording) and 4 ((field as any)?.format) are filed as objectui#7747 instead of riding along. ⛔ They do not gate the PASS and they do not hold this PR.

Everything else in the verdict stands; it was measured.

Generated by Claude Code

⛔ Ready to land, and this seat cannot enqueue it — stating the blocker once

domain:ui PM seat. This PR is finished on every gate I own. What is left is a mechanical enqueue I do not have the API surface to perform.

The three landing checks, all met

Plus all 32 check runs enumerated individually at head a43aa8101 (⛔ not the aggregate, ⛔ not a check_suite rollup): 29 success, 3 skipped by design, 0 failed, 0 in progress. Draft removed. content/docs/releases/ untouched.

What is blocking, measured

• PUT /pulls/7621/merge (squash, with expectedHeadSha) ⇒ 405 Repository rule violations found — Changes must be made through the merge queue.
• Entering the queue means enablePullRequestAutoMerge, which is GraphQL. This session answers GraphQL with: "This GraphQL query is not enabled for this session — only the pinned set of PR-review operations is served." The REST-shaped wrapper reports success but writes nothing: auto_merge reads null on re-read, twice.
• mergeable_state has read unknown since ecf14190e landed on main (PR test(data-objectstack): pin listImportMappings against the measured GET /meta/mapping body #7738) and has not recomputed across four polls over ~two minutes; mergeable is null. GitHub also declines to arm auto-merge while mergeability is undetermined, so the two failures may be one.

⇒ A maintainer clicking "Merge when ready" lands this. ⛔ I am not force-merging around a repository rule, and ⛔ I am not pushing an empty commit or re-drafting to nudge the state.

I will keep re-checking and will enqueue the moment either the state resolves or the API surface allows it. If it merges by another hand, the only thing still owed is closing card #7443 after reading merged: true — ⛔ which I will not do before that read.

Follow-ups from the review are already filed and open, so nothing dies when the card closes: #7745 (formatDate should read options.style — the condition on the boundary-flag disposition), #7746 (.github/labeler.yml has no package: fields entry), #7747 (the changeset's byte-identity wording; the free narrower cast). #7619 and #7620 remain open and queued.

Generated by Claude Code

⛔ Retracting my previous comment — this PR was already in the merge queue when I said it could not be enqueued

My comment 5552446870 says this seat cannot enqueue the PR and that a maintainer must click "Merge when ready". That is false. Retracted in full.

6m42s after it was already queued. My enable_pr_auto_merge call did take effect; I concluded it had not.

The root cause is not the one I have been correcting all day, and that matters

The three earlier corrections today (#7443, #7579, #7621) were staleness — a sentence about state written from memory instead of re-reading. This one is worse and different: I re-read four times and measured the wrong thing.

I polled auto_merge and read null, and treated that as evidence the PR was not queued. auto_merge is not merge-queue membership — they are two different mechanisms, and a queued PR stays open with auto_merge: null and can sit at mergeable_state: unknown the whole time. So my null was a true reading of a field that does not answer the question I was asking.

⇒ I used a proxy instrument, never proved it could register a positive, and read its zero as an answer. That is exactly the discipline this seat has enforced on every dev report and every contract review today: a zero from an instrument you never proved lit is not a reading. I demanded a lit control from four agents this afternoon and did not apply one to myself.

The concrete rule, added to the landing routine: ⛔ before reporting that an action failed, name the field that would show it succeeded and prove that field can show a positive. Here the authoritative signal was the pull_request.enqueued event, not auto_merge.

Actual state

#7621 is in the merge queue and will merge when it reaches the front and its queue checks pass. Nothing is owed by a maintainer. Everything else in the retracted comment was measured and stands: the three landing checks (PASS on record · needs:contract-review off both carriers · check-clause2-carriers --pair 7621 exit 0), 32 check runs enumerated individually at a43aa8101 = 29 success / 3 skipped / 0 failed, and the follow-ups #7745 / #7746 / #7747 open alongside #7619 / #7620.

⛔ I will still not close card #7443 until I have read merged: true.

Generated by Claude Code